1. Field of the Invention
This invention relates to dynamic brokering of messages between objects implemented using like or different object models.
2. Background
Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks. The building blocks in object-oriented programming systems are called xe2x80x9cobjects.xe2x80x9d An object is a programming unit that groups together a data structure (instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining of data and operations into a unitary building block is called xe2x80x9cencapsulation.xe2x80x9d In object-oriented programming, operations that can be performed on the data are referred to as xe2x80x9cmethods.xe2x80x9d
An object-oriented software application uses objects to define its data and the methods that operate on the data. An object communicates with another object via messages. For example, when one object needs to manipulate data that resides in another object or needs to execute computation methods in another object, it sends a message. The requesting object identifies the desired manipulation operation by specifying a method. The requesting object can further send arguments that can be used by the second object in performing the named method. The servicing object performs the method requested in the message. The data provided by the requesting object can be used to perform the requesting operation. In client/server terminology, the requesting object is called the client object and the servicing object is called the server object.
When the client and server objects are running in the same computer and operating system or in the same process or memory address space, the program or system can use its own mechanisms for messaging and object identification without regard for any other systems. The physical location of the objects is determined, known, and maintained by the single system. In a distributed environment, however, objects can reside on different systems and across networks, for example. Thus, in a distributed environment, a client object may need the services of a server object that resides on a remote system. Not all object models provide for such remote requests. Also, the remote system may use an object messaging mechanism that is incompatible with the client object""s messaging mechanism. In that case, the client object and server object cannot communicate or xe2x80x9cinteroperate.xe2x80x9d
An object model provides a mechanism for communication, or messaging, between objects within the model. The mechanism includes a protocol that defines the method of communication. Examples of object models include the NeXT object model, Microsoft""s Object Linking and Embedding/Common Object Model (OLE/COM), SunSoft""s Distributed Object Environment (DOE), and Smalltalk. To facilitate communication, an object model can use an object bus, or an Object Request Broker (ORB). An ORB allows objects to make requests of, and receive responses from, other objects. Examples of ORBs include CORBA (defined by Object Management Group), SOM from IBM, ORB Plus from HP, ObjectBroker from Digital Equipment Corporation, and Orbix from Iona.
An ORB uses an Interface Definition Language (IDL) to define static interfaces between objects. For example, an interface defines the methods and properties, or arguments, for each object. An interface file written in IDL is compiled to generate client and server language-specific stubs such as C, C++, Objective-C, etc. These stubs must be compiled into both the client and the server before any communication can take place.
These language-specific stubs define how clients invoke corresponding services on the servers. From a client""s perspective, the stub acts like a local call. The stub is a local proxy for the remote server object. The stub includes code to encode and decode an operation and its parameters into a compacted message format that can be sent to the server. This is referred to as marshaling. Several ORBs, including the CORBA ORB, are described in detail in R. Orfali et al., xe2x80x9cThe Essential Distributed Objects Survival Guidexe2x80x9d (New York: John Wiley and Sons, 1996).
In addition to the language-specific stubs, CORBA provides some application program interfaces (APIs) on the client-side to facilitate object communication. A Dynamic Invocation Interface provides APIs that can be used to look up the metadata that defines the server interface, generate message parameters, issue a remote call, and receive results from the call. An Interface Repository is a run-time database that contains machine-readable versions of the IDL-defined interfaces. The APIs associated with the Interface Repository provide mechanisms for retrieving, storing and updating the metadata information contained in the Interface Repository. The ORB Interface includes APIs to convert an object reference (i.e., a unique name or identifier associated with an object ) to a string.
Like the client side, the server side includes IDL stubs, or server stubs. A server stub is also referred to as a skeleton. Like a client stub, a server stub is defined using IDL and created using an IDL compiler. A server stub provides a static interface to a service provided, or exported, by a server. It calls the method on the server identified by the client. On the server side, CORBA provides functionality to aid in servicing a request.
A Dynamic Skeleton Interface provides a run-time binding mechanism to handle incoming method calls directed to a server that does not have a server stub. An object adapter provides the run-time environment for instantiating a server object, assigning an object reference to a server object, and passing it a request. An Implementation Repository is a run-time repository that identifies the classes a server supports, the objects that are instantiated, and the instantiated objects"" object references. Administrative data such as trace information can also be stored in the Implementation Repository. The server side includes an ORB Interface that is the same as that used on the client side.
Existing object models such as the ones identified above do not provide a means for dynamic communication across object models. Thus, an OLE object cannot automatically and dynamically communicate with an object in the DOE object model. When a programmer is preparing an application program that must communicate across object models, the programmer must identify the destination objects to the ORB by declaring and defining them in an IDL method file. The IDL method file is then compiled in conjunction with run-time libraries of each object model, producing separate executable files for the client and server. This process must be repeated when a method or property of an object changes or when the application program is modified to reference new objects in a foreign or incompatible object model, for example. Thus, the ORBs only provide a static means for communicating across object models. The ORB is not capable of dynamically passing a message from one object model to an incompatible object model without prior knowledge of the method.
In OLE Automation, a subset of the OLE/COM object model from Microsoft Corporation (MS), a set of object definitions (or ODL) is compiled to create a type library or repository of object descriptions (e.g., objects and their methods and properties). Before invoking a method in an object, an OLE/Automation client object queries the library, to determine whether a server object can process the desired method. To do this, the object invokes the GetIDsOfNames method on the server object to determine whether the desired method is a valid method of the server object.
The GetIDsOfNames method converts text names of properties and methods into a corresponding set of dispatch identifiers (dispIDs). A dispID uniquely identifies a method or argument. It is assigned to a method or argument in an object description file that is compiled before run-time. Thus, if a method or property is added, a new dispID must be generated and compiled into the server.
If the response from the GetIDsOfNames method returns a dispID for the desired method, the client object invokes the method on the server object using the dispID to identify the method. If it is not a valid method, the client object must handle the error. If the method exists, but an error is raised during processing, the client object must handle a different error. This is awkward because it requires the application programmer to write code to handle at least two types of error messages.
Further, this process requires the client object to send two messages. When the client and server objects do not reside on the same machine, the messages must be sent across a network between the client and server objects to invoke a single method. This increases the network""s message load, which is undesirable.
The present invention dynamically brokers object messages between objects implemented using object models. A mediating component provides a bridge between objects in these object models such that messages can be transmitted in either direction between object models. The mediating component can be resident on a client machine, a server machine, or both, depending on the type of communication being done. The mediating component can be used as a bridge between two instances of the same object model running on different machines. Thus, a networked version is created for an object model that otherwise lacks a networking capability.
The mediating component intercepts messages sent by a client object to the server object. That is, messages sent by a client object are sent to the server object via the mediating component. However, the client believes that the messages are being sent directly to the server object. The mediating component creates a mapping between a client object and a server object. Mapping information is determined by the mediating component when a client object requests a connection to the server object.
When a client requests a connection to a server object, the mediating component determines whether the server object is available on the server machine. If the server object is available, the mediating component returns a proxy (e.g., returns pointer to or identifier for the proxy object) for the server object to the client object. If the proxy object does not already exist, the mediating component creates the proxy object.
If the stub object associated with the server object does not exist, it is created by the mediating component. The mediating component creates a mapping between the proxy object returned to the client object, the server object""s stub object and the server object. The mapping information can be stored in one or more tables, for example. A table look up mechanism can be used to retrieve the mapping information.
The mapping information can be used to satisfy a future connection request. When a connection request is made for a server object, the mediating component queries the mapping information to determine whether a mapping already exists for the requested server object. If a mapping does exist, the identity of the proxy object is returned to the client object.
The client object uses the connection to send a message to the server object. A client object""s message is forwarded to a server object via the proxy and stub objects. The mediating component performs any necessary message translation. In addition, the mediating component translates a server object""s response.
The client object""s message is generated using the message protocol of the client object""s object model. The client object""s message is translated into the message protocol of the server object""s object model. For example, the proxy object determines the expected method identification and the number and type of arguments for the server object.
The proxy object builds a method invocation for the server object using the client object""s message and the information expected by the server object. For example, the proxy object translates a method identification in the client object""s message to one expected by the server object. In addition, the proxy object can translate the arguments such that the types of arguments provided in the client object""s message are the same as the expected types. For example, a string argument can be translated into an object argument.
A translated message is forwarded to the server object on the server machine via the proxy and stub objects mapped to the server object by the mediating component. The proxy object forwards the translated message to the stub object. The stub object forwards the translated message to the server object. The server object processes the message. A response is forwarded to the proxy object via the stub object. The proxy object translates the response message using the client object""s message protocol. In addition, the proxy object can translate the response such that the response type is that expected by the client object. The message is forwarded to the client object.
The mediating component delays the creation of a server machine stack until it is determined that a method is callable on the server machine. A message is forwarded to the server object via a plurality of intervening objects such as the proxy and stub objects on the server machine. The invention waits until the message is received by the last intervening object (e.g., the server object""s stub object) before the message is unraveled. Otherwise, each intervening object would retrieve the method and arguments from the message, push the arguments on a stack, attempt to invoke the method, fault, rebuild the message, and forward the message to another object. The invention optimizes the message transmission by eliminating the need to unravel the message at each intervening point.
The mediating component can be resident on the client, server, or both. The mediating component can act as a bridge between compatible or incompatible object models.